It is common for a document production environment to process a print job based on one or more parameters from a job ticket associated with the print job. Exemplary parameters may include paper size, reduction or enlargement percentage, imposition and the like. Storing all of the necessary parameter values on a single job ticket can be impractical however, especially when the parameter values can originate from multiple sources. For example, a typical prepress operator can use a variety of parameters, such as imposition, computer-to-plate resolution, screen ruling, trapping details and the like. The values corresponding to these parameters may originate from a variety of sources such as job tickets, queue overrides, metadata, Page Description Language (“PDL”) analysis results, job manifests and the like.
In addition, a job ticket may not support the required information or an application that generates a job ticket may not have access to the required information. For example, a management information system is seldom aware of a specific Page Description Languages associated with a job, and, therefore, cannot use PDL properties to populate job tickets. As such, it is important for a document production environment to determine a parameter's value from multiple sources of potential values.
Currently, the scope of information handled by certain job tickets is limited. A Job Definition Format (“JDF”) job ticket may represent a broad scope of job ticket information. For example, a JDF job ticket may include all job information submitted with the job, and the job ticket may remain with the job from creation through production to ensure proper processing. However, systems that create JDF job tickets often do not have access to information that would otherwise not be included in the JDF job ticket. In addition, systems that have information required for processing are often constrained in their ability to pass that information to processing components.
In addition, the parameter definitions for most job ticket formats are often too restricted because these formats do not support the full breadth of job ticket information required to process a job. In addition, some job ticket parameters are not found in job tickets, but are rather derived from the values of other parameters. As such, these parameters are not intuitive because there is no single source that can be used to populate a production job ticket.
Parameter values are rarely intuitive and the parameter definitions are usually too restricted to fully automate an advanced workflow. Moreover, requiring a user to remember parameter names and accurately enter them discourages a user from using such parameter values. Typically, a user examines and revises print jobs based on the print job requirements prior to dispatching the print jobs to an automated workflow. This approach presents many drawbacks, however. For example, it is extremely easy to inadvertently enter invalid variable names. Moreover, the current approach uses variable values in their entirety, which does not provide the flexibility needed to automate processing decisions. In addition, parameter names cannot be used to set derived values.
Because parameter values may be determined based on a variety of content from a variety of different sources, each of which may or may not be known, determining the sources of parameter values often occurs piecemeal, and users are often unaware of the source of the values used.